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(54) Resource reservation in 3G or Future Generation telecommunication network (iv) 



(57) In the UMTS, resource reservation is provided 
by using unidirectional RSVP messages to set up a bi- 
directional PDP context. The MT 30 and a support node 
24 can be arranged to compare incoming RSVP mes- 



sages with any existing secondary PDP context, and if 
a match is found, no action is taken on the incoming 
message. The match is made by detemnining whether 
a flag is set. This eliminates "racing" when each end of 
an RSVP session sends an RSVP message. 
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Description 

[0001] This invention relates to teleconnnnunlcations 
networks operating the Internet Protocol (IP), and re- 
lates especially to a method of reserving resources. s 
[0002] In third generation (3G) telecommunications 
networks, such as Universal Mobile Telecommunication 
System (UMTS), broad bandwidth is provided for serv- 
ices such as data and multimedia In addition to voice. 
An obvious need is that required Quality of Service 
(QoS) should be provided to users, but in IP networks, 
If contention for resources is not resolved, then QoS 
cannot be guaranteed. 

[0003] In IP networks or the Internet in general, Re- 
source reservation Protocol (RSVP) is used to allow the 
network to reserve resources so as to provide QoS. 
RSVP can be used for QoS control locally or it may be 
used across IP networks. 

[0004] RSVP is an end-to-end protocol and is illustrat- 
ed in Figure 1 . A transmitting user 1 0 sends to a receiv- 
ing user 12 a message PATH. The PATH message car- 
ries the traffic characteristics information such as 
Tspecs to indicate the traffic behavior that is to be sent 
from the user 10. When the receiving user receives the 
PATH message, it sends a RESV message which con- 
tains QoS requests such as FlowSpecs. In practice, the 
transmitting and receiving users 10, 12 can be located 
remotely so that PATH and RESV messages pass 
through several nodes in UMTS. As each node receives 
either of the messages, it makes a decision as to wheth- 
er adequate resources in that node can be reserved. If 
this is possible, then the messages are relayed to the 
next hop for the PATH message and to the previous hop 
for the RESV message. When the RESV message 
reaches the transmitting user 10, it begins to transmit 
data. 

[0005] Periodic refresh messages are sent subse- 
quently to maintain the QoS status at each node in which 
it has been set up. 

[0006] At the TSG-SA Working Group 2 meeting no. 
1 2 in Tokyo, 6-9 March 2000 a disclosure was made by 
applicant of arrangements in which a mobile system us- 
ing RSVP can communicate across a GPRS/UMTS net- 
work with another RSVP user; a proxy activated by the 
mobile receives and processes PATH messages and 
generates RESV messages in return. 
[0007] Applicant's copending European patent appli- 
cation no. [Lucent Case Name/No. X. Chen 11/ 
IDS No. 122413] filed on even date describes an inven- 
tive method in which RSVP messages are filtered at a 
mobile and at a Serving GPRS Support Node (SGSN) 
or a Gateway GPRS Support Node (GGSN), and the 
mobile and the support node are arranged to activate 
Packet Data Protocol (POP) Context Activation Proce- 
dure. However, conflicts can arise in certain circum- 
stances. 

[0008] It is an object of the invention to provide a 
method of reserving resources in third or future gener- 



ations of wireless mobile networks such as UMTS which 
has no or minimal impact on existing architecture or QoS 
procedures, that overcomes the aforementioned con- 
flict. 

[0009] According to the invention, in a third or future 
generation telecommunication network, a method of al- 
locating resources for user traffic passing between a 
mobile temninal and a remote user, characterized in that 
unidirectional Resource reSerVatlon Protocol (RSVP) 
messages arecompared so as to detect any previous 
RSVP message for that session. 
[0010] Preferably a flag is arranged to indicate that an 
RSVP message for that session has already been sent. 
[0011] In the accompanying drawings, Figure 1 illus- 
trates the operation of RSVP, The invention will be de- 
scribed by way of example only, with reference to figures 
2-5 in which:- 

Figure 2 illustrates schematically the UMTS QoS ar- 
chitecture for the control plane; 
Figure 3 illustrates the interchange of messages in 
an uplink; 

Figure 4 Illustrates the interchange of messages in 
a downlink; 

Figure 5 illustrates the uplink interchange of mes- 
sages in an end-to-end session; and 
Figure 6 illustrates the interchange of messages in 
a downlink direction. 

[0012] In Figure 2 the UMTS 20 comprises a Core 
Network (CN) 22 fornied by a Gateway GPRS Support 
Node (GGSN) 24 and a Serving GPRS Support Node 
(SGSN) 26; there is also a UMTS Terrestrial Radio Ac- 
cess Network (UTRAN) 28. A MT30 communicates with 
the UTRAN 28 across a radio interface. The MT 30 is 
connected to Terminal Equipment (TE) 32 which may 
run non-UMTS specific applications. The MT 30 is 
UMTS specific, and is capable of processing the traffic 
from the TE 32 to channel it appropriately to the UMTS, 
usually to the radio access network. 
[001 3] The GGSN 24 communicates with an External 
Network 40. 

[0014] The UMTS 20 operates the application-specif- 
ic Packet Data Protocol (PDP) context as usual to ne- 
gotiate the QoS and activate the QoS control between 
the MT 30 and UMTS network 20. 
[001 5] Figure 3 Illustrates traffic QoS in the uplink di- 
rection. RSVP messages are tenninated only at the MT 
30. The RSVP processing entity in the MT30 is triggered 
by a PATH message from TE 32. In response, the MT 
30 filters the message, analyses the RSVP parameters 
carried in the PATH message, and takes a decision 
whether to modify an existing secondary PDP context 
or to create a new secondary PDP context, to provide 
an updated QoS status. The secondary PDP context is 
then create/modified using the existing PDP Context 
Control procedures. If the PATH message is a first-time 
PATH message, a new secondary PDP context is cre- 
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ated. If the PATH message is a refresh message with 
no modified QoS parameter, then no action is taken. The 
activate secondary PDP context message is sent by the 
MT 30 across the UTRAN 28 to the SGSN 26, which 
generates a create/modify PDP context Request mes- 5 
sage and passes it to the GGSN 24. Return messages 
from the GGSN are processed similarly by the SGSN, 
and the MT 30 filters the message and passes a RESV 
message to the TE 32. The TE 32 may send a refresh 
PATH message and receive a refresh RESV message. 
[0016] An important feature of RSVP is its uni-direc- 
tional QoS request delivery. Specifically, the QoS status 
in the uplinlc direction set up by using RSVP does not 
apply to the QoS status in the downlinl< direction. This 
means that a QoS status that applies in both uplink and 
downlink requires two separate RSVP session set-up 
processes so as to be in line with the two way QoS status 
as contained by the PDP context of UIVITS. This increas- 
es the QoS session set-up time and further complicates 
the QoS control and management in separate direc- 
tions, because each direction needs to be controlled and 
maintained separately. 

[0017] However, there is a problem which may be 
tenned a "racing" problem because an RSVP terminal 
may not be UMTS aware, i.e. it may not be aware of a 
two-way nature of UMTS secondary PDP context. Then 
each end of an RSVP session may send RSVP mes- 
sages Independently from Its remote peer. This means 
that the GGSN 24 will receive two PATH/RESV messag- 
es, each of which applies for each direction (one for up- 
link and the other for downlink). The same "racing " prob- 
lem occurs when the RSVP messages are terminated 
only at the MT 30. 

[0018] This racing problem has not previously been 
recognized. In the present invention the problem is re- 
solved by checking if there is any existing secondary 
PDP context associated with RSVP QoS status by 
matching the end point information contained in the PDP 
context in comparison with the incoming RSVP messag- 
es. If no match is found, then no action will be taken 
upon receiving an RSVP message which will then be 
transparently delivered to the remote peer end as be- 
fore. 

[0019] In Figure 3 the points at which such message 
comparison takes place, In the MT 30, are Indicated at 
M. 

[0020] In Figure 4, which Illustrates a downlink, RSVP 
is terminated only at the MT 30. The session is initiated 
from the External Network 40 and message processing 
Is similar to that In Figure 3. The message comparison 
points, which may be in the MT 30 or the GGSN 24, are 
also Indicated at M . 

[0021] Figures illustrates a variation in which a RSVP 
session is used end-to-end and is terminated at the MT 
30 and the GGSN 24. The assumption Is that TE 32 In- 
tends to set up an RSVP session with its remote peer, 
which also uses RSVP signaling, in the External Net- 
work 40. The Figure shows RSVP activated QoS In the 



uplink direction. When the MT 30 received a PATH mes- 
sage from TW 32, it checks to see if a PDP context exists 
for this RSVP session. If it does, the MT 30 triggers the 
Modify PDP context message If there Is a change In QoS 
parameters. 

[0022] When the PATH message is received at the 

GGSN 24, it uses this infomnation, again along with rel- 
evant local configuration, to see if QoS Negotiated is the 
same as QoS Requested. The PATH message Is then 
sent to the external network. Radio Access Barrier 
(RAB) negotiation can take place between the SGSN 24 
and the UTRAN 28 if QoS Negotiated is different from 
QoS Requested. Finally, the RESV message returned 
from the external network Is filtered by the GGSN, which 
creates or modifies a PDP Context request message, 
which is sent to the MT30. 

[0023] The message comparison points in the MT30 
and the SGSN24 are again indicated at M. 
[0024] Figure 6 shows the end-to-end situation for the 
QoS control in the downlink direction with filtering In the 
MT and GGSN. 

[0025] As before, the message comparison points to 
prevent the racing problem are Indicated at M. 
[0026] To overcome the racing problem, the compar- 
isons at the point M can be made, for example, In two 
ways, both involving use of a flag. 
[0027] In a first arrangement, a flag is made available 
In every PATH and RESV message by addition of a flag 
bit. 

[0028] For an MT-only temninated arrangement, for 
every session, the flag is set by the MT 30 the first time 
a RSVP message is sent or received by the MT30. The 
flag is sent to the receiving end in the RSVP message 
for this session, and the receiving end recognizes that 
it does not need to send a return RSVP message for this 
session. The message In which the flag is set may be 
either a PATH message or a RESV message. 
[0029] If the flag has not been set, then no RSVP mes- 
sage has been sent and there can be no racing problem. 
[0030] For an MT and support node tenninated ar- 
rangement, either the MT or ghe SGSN/GGSN can set 
the flag. In this arrangement, the MT 30, the GGSN 24 
and the SSGN 26 need a small modification so that it/ 
they can set the flag bit and recognize when the bit has 
been set In a received message, and to act (or not act) 
appropriately. 

[0031] In a second arrangement, a session flag Is 
made available in PDP Context, which carries all the in- 
formation about a session. The session flag can be set 
by either the MT 30 or the GGSN 24 or the SGSN 26. 
[0032] For example, when the GGSN 24 receives a 
first RSVP message (whether it Is a Path or a RESV 
message) it sets the session flag in PDP context; the 
RSVP message is sent by the GGSN in a first direction 
to the remote end; It is to be understood that the remote 
end does not receive a flag. When a return RSVP mes- 
sage in the opposite direction is received by the GGSN 
24, It checks If the flag Is set for that session; If the flag 
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is set, the GGSN discards any further RSVP messages 

for that session, therefore the racing problem is avoided. 

[0033] The GGSN also checl<s to see if the QoS re- 6. 

quirement is the same as in the PDP Context sent out; 

if the QoS requirement is higher, the GGSN actions the s 

Modify Existing PDP context protocol. 

[0034] Usually a customer will have the option of de- 7. 
elding whether to change the QoS if it is lower than the 
present QoS requirement. 

[0035] In the first arrangement according to the inven- io 
tion with a flag in the RSVP message, the IVIT 30 pre- 8. 
vents the racing problem and the remote end does not 
pass on the RSVP message. The first arrangement can 
be applied to messages as shown in Figs 3 and 4 in 
which RSVP messages are filtered in the MT 30 only 15 
[0036] In the second arrangement according to the in- 
vention with the flag In the PDP context, the GGSN pre- 9. 
vents the racing problem and the remote end does not 
pass on the RSVP message. The second type of flag is 
applicable to messages as shown In Figures 5 and 6 in 
which the RSVP messages are filtered at the MT 30 and 
the GGSN 24. 

[0037] By such comparisons at any of the indicated 
positions, the aforesaid "racing" problem is overcome. 
[0038] Either a RSVP message can be intercepted in 25 
the MT and the SGSN or GGSN 26. the MT or support 
node then initiating PDP context activation procedure, 
as described in applicant's copending European patent 
application no. [Lucent Case Name/No. X. Chen 1 1 / IDS 
No. 122413] filed on even date, or the RSVP messages 30 
can be "piggybacked" in an IP paclcet , as set out in ap- 
plicant's application no. 00301782.9 filed on 3 March 
2000. 



Claims 

1. In a third or future generation telecommunication 
network, a method of allocating resources for user 
traffic passing between a mobile terminal (30) and 40 
a remote user characterized in that unidirectionat 
Resource reSerVation Protocol (RSVP) messages 
are compared so as to detect any previous RSVP 
message for that session. 

45 

2. A method according to Claim 1 in which a flag is 
arranged to indicate that a RSVP message for that 
session has already been sent. 

3. A method according to Claim 2 In which the flag is so 
provided as an additional bit in every RSVP mes- 
sage. 

4. A method according to Claim 2 or Claim 3 in which 

the mobile temiinal (30) is arranged to set the flag. 55 

5. A method according to Claim in 4 in which the mo- 
bile terminal (30) is also arranged to sense the pres- 



ence of the flag. 

A method according to Claim 1 in which the flag is 
a session flag and is provided in Packet Data Pro- 
tocol (PDP) context. 

A method according to Claim 6 in which a support 
node (24) of the network is arranged to set the flag 
and to send PDP protocol In a first direction. 

A method according to Claim 7 in which the support 
node(24) is also arranged to sense the presence of 
the flag in PDP Protocol received in a second direc- 
tion and to discard any subsequent RSVP messag- 
es for that session. 

A method according to Claim 8 in which the support 
node (24) is also arranged to detennine whether a 
Quality of Service requirement in the PDP message 
Is higher than the Quality of Service requirement 
currently applicable to the session , and if so to mod- 
ify the existing PDP message. 
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P D P ^ -b-i^^iijE-r § J: ^ c i: ^Itm 

t-r^m^msmi(o:^mo 40 

[000 1] 

Dhn-;I/ (I p) ;&i!j{t^-a:5®m*>y hy-i'CM 
[0 0 0 2] 

[|ie*<OM MHffif^ (3G) Ojiffl*-y hy-^/, 
tJljK.ffa-y^— 9-;l/^E(l5i^S/XTA (Universal Tele 
communication System ; UMTS) (CioVTti^ ItM 



nmZO 0 2-9 8 4 0 

2 

Jj-71t-ex (Quality of Service ; Q o S) 

^{cfi, Q o S ^Um.t?>c t i3'^X't^\>\ 
[0 0 0 3] I P^>y h7-i7a55V»^y^f-:^'y h 
-MfC^SVTfi^ K®^3|<i:^P b3-;l/ (Resource reS 
erVation Protocol ; RSVP) ^ffi</'>T^'y hy-i' 

R s V Ptt. ;^mw*Q o s (DMmmiz^?>\>Hi i 

[0004] RSVP a. i^*H©ya h a~)lT'^ 

1f 1 2lCp<>y-tr-yPATH^j^fi-r-5o COPATH 
^-y-fe->?{i. ^•57^••y^#tt1flB. glJAtfTspecs^ 

ms^LT. aififflia.— y 1 0)b^63i®^n5'^th77 

-i"y^'CD¥ij (traffic behavior) ^^LTV''2>o S€ 
fiija— If 1 2 P A T H ^ -y ■fe-i'^SM-r ^ i:, R E 
SV (giliiSI«) ;?<>yb-':^%SiD, C<D^'y^-i^li 
QoSUi^xXb, efl^{f7n-X'^-y^ (FlowSpecs 

[0 0 0 5] usEfcfi, jjnifflu^.— »f 1 0 t^mm=L- 
■(f 1 2 immmmntcmmc^tE u p a t h ^ -y -t 

-i^ i: R E S V -y -fe- v'tt U M T S F«3«SC*moy - 
K^riiJa-rSo =&/-K*^E:ne©><-y-b-S^©l^-fn 

S) *'«fflit$nTV^§A^SA^<DSfe^}b^t>n5o fflM^ 
nTi^^sa^fctt, ^-b-S^fiP ATH:;{>y-tr— >*Jc5^ 
tT«5)J^04-^•y rtCffli^n. R E S V ^ «y-b— >'JC)hf 

tTi±Hu©3^-y :^C(pj«^n«o RES vy >yt— 

SIMfflOn.— If 1 0 fCPMTS Smffllla— If 1 0 liT* 

[0006] mmff3^J:0 7 U-y v-a ^ -y •fe-v'd'^-O^ 
Q o SttgS*W?tlfc#/- KlCfeV^Til 

oQo s«^^ii»-r^o 

[0 0 0 7] 2 000¥<^3^6~9atT'^T-Bi*^ 
nfcT S G-S A-:^7-*V^-5^;Wr05— r-C V 
i^No. 1 2{i:feV^Ta. R S VP^SrffiV-^^lfii/Xf- 
AA^GPRS/UMTS^^^-y hy-^'^/rtTgijoRS 
VP3.— *f-i:ji«U ^i)BCJ:!3S«i^nfc:/D4^ 
-> (proxy) tj^^mL. P A T -y -fe-i/'^jaa 
tr R E S V ;>< >y -t-e/*:&f^^D ?) fC^fe^-r 5 J; S:*^ 

[0 0 0 8] :!^mmm(omBKiiimLrznmihm m 

S#^A 1 00 7 7) t*JVTfi. RE S V?<>yfe->' 
fix ^»l^i:1^-excf©GPRS-9-4^-hy-K (se 
rvlng GPRS Support NodelSGSN) m'^li.^-h^ x-i G 
PRS-9-4^-by-F (Gateway GPRS Support NodelGG 

SN) T"£>oT7-f;i/^-Ma^tiT. ^mmt-^t^-h 

/— Kfi/^-iT'y bv'-:?:/a (Packet Data Prot 



(3) 

3 

ocol ;PDP) hett^H^fiKcrs J: ^filfiKS 

CO 0 0 9] ixJb^u ayyvirh mm ttfesao 

[0 0 10] 
[00 1 1] 

«^i^fliaT57^ffiE:feV^T. HlfOffiicOR E S >y 
l^yu h n;l/ (Resource reSerVation Protocol ; R S V 

p) ^y-b-v^^itit-rsiit^^mfcrs. »*l< 

{±75 ft!<^ay^ -J -> 3 yoP^ R S V P <y -tr-i^ij^K 20 

{cjMii^ tifc c: t ^m-i. 5 Begins, 

coo 1 2] 

ilMv'Xf-A (UMTS) 2 0{±, y-h-fx-rGPR 
S'<f:a<-hy-H (GGSN) 2 4 fc^t-lfX^'OG P 

RS-9-4^-hy-K (SGSN) 2 ejcio^i^^n/c 

37:?^-yh7-^' (CN) 2 2^Wr^o |i!^»c*fcU 
MTS«&±ftl^7^-b;^^-y by-i' (UTRAN) 2 
8^^f5o ^©4^515 (MT) 3 0«. it^'T^^yx 
-:^^r/l-LTUTRAN 2 8 taSTSo MT 3 OfiSS 30 
?gS(TE) 32JCg«g?n, i:©MT30«gpUM 

Tso!|t^7:/';^->'3y%i!i*^-ro mtso^um 

TSmX\ TE3 2!b^€.UMTS's0^i'^;k 

[0 0 13] GGSNi?-Jj<-hy-F2 4li^1-gB^-y h 
7— ? 4 0 l:a©-rS, UMTS2 0l±> jimiil377 
U-ir— >3 VftfigOr-^/^^r-y bT'n (Pack 
et Data Protocol, PDP) ^rSli^^-ti:, Qo S^rSfffi 
LTMTSOfcUMTS 2 0t<OH©QoSSiJ^*Si!l 40 

[0 0 14] 03tt7>y7U>'i':5(RlcDh57-<'-yi^Q 
oS^S-To PATH^f-y-b— MTSOtD^'^ffl 
■r?.. MT3 0rt©RS VPSQ,ax>x^'X'C-aTE 
32*^?>cDPATH;^'y -fr-i/**^? I i: ^ ^ TKlff ^ 
Wjia-rSo ^ti{cjSStTMT3 0t±^'yb-y*7i' 
LT P A T H -y -fe- v'rtTfi63l^ni> R S 
VP-'^^^-rJ'^^WU Kl^OrijijPDFa^T^^^X 
V^mJEt^tl>^ii\ e2W±ifrc*-^PDPayr+ 
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4 

m^U^t^o -?^PDP3>x+xMi^0ttK#0 

p D p avx^^x ^©J^9#Jl^:fflv^T4B^/ii^iE^n 

So PATH;>««yb-e^*^Sl2IOP ATH><>y-lr-i?-e 
« Single «Sfffc;a:r:^ P D p n vx^x h*^4fiSt^n 
5o P ATH;^-yfe-i^*'«Qo S>'^7P<-^f5rifjELT 
t/^^v>U 7 U^y ^nfc;?« <y ■tr-i^©ig-&fctt, 
(D7i'i^3yfeUP)*v\ ?S14^nfcZi:j>;PDPay7^ 
h -y -fe-i^A^M T30{Cj;t)UMTS ^IMWT 
^•^:^^yYV-^ (UTRAN) 28^:n'bTSGS 
N 2 GfCiMSnfcJi^Ka, CCOSGSN26t±PDP 

n^y-hyx-rcpR (ggsn) 

2 4 fcjMSo G G S N 2 4 *^5>M*n/!:;< -y -b-i^'tt S 
G SN 2 GT-iHieiEjaffiSn^ MT 3 0^iC:<D;<•y-b— 
v'^7^';^:^^-S!laL.TRE S Vp<>y-t-S/*^TE 3 2 
KJMSo T E 3 2 ttU 7 P«y P A T H>« y^-V^ 
3MC)> ^LT'J7U'>y2^iRE S V;>«yfe-5^?:§tt|X 

CO 0 1 5] R s V po«s*i#aa, ^-tiJb^-T^iBHc 

Si:, RSVP^fflV>T^^n«:7<y:/''J>'^:^(Rl<D 

Q o s^^aif'»u>'i':&(RioQ o s*5ii{c®ffl-r5 

i^(Dm:^icmmiEmQoS^i±. umtsopdp 
3Vr^;^ hfc^Sns J:'5*2;5r(R]©Q o Stt^fcS 
-^^t^tzltKlis 20(DSlJffl(DR S VP-t>yi/3y«0 

J:»3QoS-b-yi/3VlS^ltra6^iSinU ^StciigiJO 

[0 0 16] UA^U, ruz-i/y^ (racing) J t^T^-f 
^mmt^&^o ^©Sfiti. R S V PiSjRttUMT St 
■OVTOftlil, Ep-5^7^[RlcOUMTSr^PDP3V'r 

a %t^SlCfcV>T, R S V P -fe >y 3 yO^jmK't 
OMf^mcSb^ms^^ (peer) *^e.aiZ:tCR S V P ;^ 

PATH/RES V;><>yfe-y^§fiU ^-n^nA^^- 
y i^J r«gS{± R S V P ^« >y -t-v^A^M T 3 0 {cc7)iii'«€ 

[0 0 17] L.(ou-yymmimmimmt^rixit 

v>^A-'o/c„ *5IHJfc<}:n{J, ccDBgMfiPDP^yx 
*XhtJ:^$nsi^pR1«IBfc3)5AR S\?}iyb—i?^ 
ltlSbTV<y^y^:&i:Sili:{C<fc»3, RSVP Qo 
S ttfigfcMS-rSK#0-i^ P D P n y-r+X h A^#ffi 
t-SA^SA^^r^x-y^-rSCttCiOP^^nSo V«y 
^^i'A^l.V^fc-arftV^^&Ktt, R S V Pp< <ytr-i^^ 



(4) 

5 

s V p ^ -y ■{z-'Mmmicmys<Diti!i:s^^ic^<Dm^M 

[0 0 18] 03(CS^t,>TttMT3 OrtT'ilfiDj:d*;>« 

[0 0 1 93 m4ii^^yv>^^WiU mmicni^^x 

RSVPtiMT3 0tCCO*^8©-r«, COy-tyi/ayii 

StDfrtVlcmmr^o MT3 0X«y-h'>x-l'GPR 

(GGSN) 2 4-CfTfcn5^y-t- 10 

[0020] UStt, RS VP-b-yi/3yA^ffi*KT*ffl 
l/^^n, RS VP^>>-b-v^'A\ MT3 0ty-h'i7i 
f'GPR S-9-;H-hy-K (GGSN) Z Alcmmt^ 

^mm^^^to i^mmm 3 2 tis^ojtjsgPT' r s v p 

h7-^4 OrtT'R E S VM^^M^m^^^C 
BU^tcLTV^So |H|0t±7-y7'U>i';5[Rl<DR S VPiH 
il^n/cQo S^a^fo MT3 0*^iffi5|5SB3 2!b^e>P 
ATH;)<>yfe->^^§ffi-r-5fc. MT30(iC:©RSV 20 
P -fe >y 3 yfc5Sfr -5 P D P 3 h tm^T^ii^ 

a. MT3 0«Qo S/^v;^-^'(D'^'fC^{k*^$.5«^ 
fcttliEP D P nyr+x b p{ yt-i/:^^t^o 
[002 1] PATHp{-yt-J?«y-b'>x-l'GPR 
S+^-53^-hy-K (GGSN) 2 4jb^SM-r5fc. ^~ 
b'>i-l'GPRS-9-d<-b/-K (GGSN) 24ail 

S (QoS Negotiated) A^S^^nftQ o S (QoS Request 
ed)tSJS:Sil^{ca. »i®7^'-bXAU7 (Radio Acc 30 
ess Barrier: R A B) t!rWi)\ h'^x-T G P R S1t 
:J^-hy-K (GG SN) 24tUMTSm±mm7^ 
(UTRAN) 2 8 <DHT?fTt3n«o 
h'7-^'*^6.M^n/cR E S V;/>y■tr- 
i^^GGSN24*<7^■;^^^-®abT, CCDGGSN 
2 4)!)^PDPn>"f4^XhUd^X7.h;?{>y-lr-i/^4jat 

[0022] MT3 0fcy-h'i'x-l'GPRS^d<-h 
y-K(GGSN) 2 4Ki3lf^;i'yt-i^im^-^> 
V^MX'^to 40 

[0 0 2 3] melt. MT 30i:GGSN2 4T7'«';l/ 

[0 0 2 4] Bf(i:|B|«tCb-v'>'>/OH®*llS-r5fc 
[0 0 2 5] (KDb— >>'yr<g®jSr<PSt-r<5ftJi)JC4^-l' 

T0 20(D:^iS (Sifig) TtTfenSc 
[0 0 2 6] m-<ommcis\,^xii. y^^i,iy^^\£ 
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i: R E s yt-i^xmm'^mx$>^o 

[0 0 2 7] ^-b-yS/s Mi::fcl/^TMT{COWC«€-r 
SMfiRKfeV^Ttt. 77i^tt, RS VPjt<yfe-S?*^M 
T 3 0TiM§€^n5g?)]{CMT 3 OtCiOS^^n 
5o 77i^ail(D-fe-y->'3 R S VP^{-yfe-i;' 

U^-:yRSVP;^-y-b-'>'%j^ffiTSifcJ-S*^^V^ 
ci:^r«Bl-rs, 77i^A^i9:^5nft;><>y-b-i;{i. P 
A T H p« >y -tr— fca R E S V .y •fe-v'Ol-'Tn*'' 

[0 0 2 8] 75^^A^^^^n^l^:^^{caR E S 

[0 0 2 9] MT t^t^-hy~h'xmmr^mmc^ 

V^T«> MTSfcaS G SN/GG S NOV'-fn*-'3!)^7 

h'>X'l'GPRS-9->-K-h7-H (GGSN) 2 4 t S 
GSN2 6tt77ye«yh^|g^U (KOe-yhd^Sfi 
;<«y-tr->'rt(c|g^?nmjiS«SiSU jS^Cfrgl^ 
Sci-r (*^V>liec::J:&i,-'J;'5{c-rs) fcJ6{c. 75 

[0 0 3 0] ^2CD«ESc{CfcV>Tt4. -Iz-yi^a >75^y 
«^ -b -y 3 >CM5i-r 51t«€)±T^ieS1-5 P D P 

MT30. -y-h-i/x'TGPRS-y-^-hy-K (GG 
SN) 24, SGSN26 cOV>-rtl*^T'S^^n^c 
[0 0 3 1] mtfy-h'i^xl'GPR SlJ-^^-h/- 
K (GGSN) 2 4 1 R S V P ;^ y'iz-'J (Cltltt 
P A T H 7 -fe-v^Srcti R E S V / -y ■b-i^Ol^-fn 
A^) %S^U PDP3>'r+;^hF«3T-b'yi>'3y7v 
if^^^t^t. RSVP^-y-b-S^agi:^[RiT'iSPi 
^5|?tCG G S NIC J: Dj2lffl$n«, jiPSiffi5R«, 77if 
«r§^U%i.->o R3*:)?IfiI<0';^'->'RESVpf'yfe-i? 
^^*-h'>x-rGPRS^?-;J^-h7-K (GGSN) 2 
4 i:, •^©•b >y 3 y{C77 ii'i^^S^nft 

6>S*^*^x>yi7U 77y*^SS^$nfc»&{C{i, G 
G SN[±^©-b>y v'3>{Cfclt5-?-niJ(±OR S VP^ 

•y-b-y^nii-rso ^(orc}!bu—>y'if<DmmiimM 

[0 0 3 2] GGSN«, Qo SSftA^j^ttJ^n^cPD 
P a^T^X hrt«tOi:|Bi-*''S*''**«/i:*tC^x 
•y^fSo Qo SSff35»UO?i5V'«^K:fi, GGSN« 
^TEU^ P D P a y-r +X h :/d h nyl/^SIfTT 

[0 0 3 3] a#ii§«> ^nAmii<DQ o sm^i. k) 
t^st^^-^jctt. QoS ^^s-rsA^si^oj^^^-rs 

[0 0 3 4] 77y^R S VP;<>yfe->'rt{C*r-r5* 
HB^OH 1 0«fig(c:fcV^Ta> M T 3 0 liU-iyyiff^ 



(5) 



H 1 (Ommt. R S V P p< >y -b- v'jb^M T 3 0 rt 1? 

[0 0 3 5] 7^iJ''^PDPn>'x+;^hrttcWr5* 
^TO^Dm2©^ifi!^^ct3^^T^i. G G S Nf^ly-iyyifm 

m^wim LT> R s V p ^ y ^-i^^mt 

soiiy-h'j'x'rGPRs-y-jj^-hy-H (ggs 

-tr-i/'t^fflnr^-efeSo 10 
[0 0 3 6] &M<om^Lrzmmx-imtictizi: 

[0 0 3 7] R S VP;<>)/-t-v^*^MTt SG SNSfc 
«GG SN2 6-e«SJ»3$nSi:s MTt;rc{i+^.-l^-h 

y-F«PDPnyr4^7.he«i^(i^pgi!&-r5o cn 

ttlSI-HliaHOSSS^A 1 0 0 7 7 0^fFWffl»fcM 
^^nrv^So SSVHiR S VP;^'yb-v^tt I P>'^'^ 

/^IfflFaiiSSIO 0301782. 9# (IHISB 2 0 0 0 
^3^3 0) {crj^?nTV^?,„ 20 

[0 0 3 8] !^mm^<r>mc^m<Dmmmf¥(Dmicm 
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[Esoffim^sjm 

[01] RES vwifii^^^-riao 

[02] SiJ^yi'-MC^-rSUMTS QoS7-4^ 
[0 3 ] 7 >y :/'J y^iOBif^ ^ -y -b— >*cD5g^^g-r 
[04] ^^yvy^K^if^^yk-'J<D^^^t 

[0 5 ] a Mcfelt 5 ^ <y -b-J^OT -y 7" 

[06] ^^'>>"Jyd7:^|qIfi:felj-5;<-yfe-i/*<D^^^ 

[??F^<OBJH^] 

1 0 j^^Ufflri— tf 

1 2 S®{D3.-1f 

2 0 a-^'^— 9-;l/i^fjaM'>XxA (UMT S) 

2 2 3T^>-y h7-^ (ON) 

24 y-h'>x-l'GPRS-9-.i<-b7-F (GGS 
N) 

28 UMTSmimmT^-iiX^yhU-^ i\]TR 
AN) 

3 0 i^ffil«g* (MT) 

3 2 4a?S« (TE) 

4 0 



[01] 



[02] 
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2^ 



'i»xx>-=atppp3>»^jtt.gat <pATH) 
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